14장. 결론

출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 장연호 옮김, 제이펍 2026) | 공식: https://www.jpub.kr/

책 전 13장의 통합 — 결합을 두려워 말고 균형을 찾아라. 모듈성·복잡성·결합은 같은 한 가지 힘(공유 지식 × 거리 × 변동성)의 세 얼굴이다. 균형을 찾는 것이 소프트웨어 설계의 본질이다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 모듈성과 복잡성이 왜 같은 힘의 반대 방향인지 설명한다.
• 결합의 세 차원(강도·거리·변동성)이 어떻게 균형 공식으로 통합되는지 정리한다.
• 1~13장의 각 모델이 균형 잡힌 결합의 어느 조각인지 위치를 매긴다.
• 실무 설계 상황에서 "어느 차원을 조정할지" 의사결정 가이드를 적용한다.
• 균형이 고정 상태가 아니라 지속적으로 유지해야 하는 상태임을 이해한다.

전체 흐름도 — 책 14장 지도

[ 1부: 결합의 본질 ]
  1장: 결합 = 연결. 필수 vs 우연
  2장: 커네빈 — 복잡성의 유형 (단순·복잡·혼돈)
  3장: 상호작용 — 자유도·제약·복잡성의 발생 원리
  4장: 모듈성 — 결합의 반대편, 변경 용이성의 기반
       |
       v
[ 2부: 결합의 세 차원 ]
  5장: 구조적 설계 모듈 결합 — 강도의 분류 (6수준: 콘텐츠~데이터)
  6장: 공생성(Connascence) — 지식 결합의 정밀 측정
  7장: 통합 강도 — 5·6장 통합: 계약/모델/기능/침입 4수준
  8장: 거리 — 수명주기·물리적·조직적 거리
  9장: 변동성 — DDD 하위 도메인으로 변화율 예측
       |
       v
[ 3부: 균형과 재조정 ]
  10장: 결합 균형 공식
        BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY
  11장: 결합 재조정 — 균형이 깨졌을 때 어떻게 돌아오는가
  12장: 프랙털 — 같은 원칙이 메서드부터 시스템까지 반복 적용
  13장: 실제 사례 연구
       |
       v
[ 14장: 결론 ]
  모듈성 + 복잡성 = 공유 지식 × 거리의 두 방향
  통합 메시지: 균형 잡힌 결합이 곧 모듈식 설계다

0. 사전 필수 용어 (책 핵심 개념 종합)

• 결합 (Coupling) — 두 구성요소의 연결 관계. 제거 대상이 아니라 관리·균형 대상. (1장)
• 모듈성 (Modularity) — 미래 목표를 지원할 수 있도록 변경에 필요한 인지 부하를 최소화하는 설계 능력. (4장)
• 복잡성 (Complexity) — 시스템을 변경하거나 이해하는 데 드는 인지 부하. 지역 복잡성(낮은 강도 + 가까운 거리)과 전역 복잡성(높은 강도 + 먼 거리)으로 나뉜다. (2·3장)
• 공유 지식 (Shared Knowledge) — 구성요소가 서로의 책임·구현 세부에 대해 아는 양. 클수록 함께 변경될 가능성이 높아진다. (1장)
• 통합 강도 (Integration Strength) — 공유되는 지식의 종류와 범위: 계약·모델·기능·침입 4수준. (7장)
• 거리 (Distance) — 구성요소가 얼마나 떨어져 있는가. 추상화 수준·런타임 결합·조직 구조 등 기술적·사회적 요인이 영향. (8장)
• 변동성 (Volatility) — 구성요소의 예상 변화율. DDD 하위 도메인(핵심·지원·일반)으로 예측. (9장)
• 균형 잡힌 결합 (Balanced Coupling) — BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY. 세 차원이 최적 상태를 이룬 설계. (10장)
• 공생성 (Connascence) — 한 부분 변경 시 다른 부분도 변경이 필요한 종속 관계. 정적(컴파일 시) + 동적(실행 시). (6장)
• 프랙털 설계 (Fractal Design) — 결합 원칙이 메서드 행 → 클래스 → 서비스 → 시스템 모든 층위에 반복 적용되는 구조. (12장)
• 수명주기 결합 (Lifecycle Coupling) — 함께 구현·테스트·배포해야 하는 결합. 거리에 반비례. (8장)
• 커네빈 (Cynefin) — 단순·복잡·혼돈·무질서 4영역으로 문제 성격을 분류해 설계 접근을 결정하는 프레임워크. (2장)
• 필수 결합 vs 우연 결합 — 목적상 반드시 필요한 연결 vs 설계 부주의로 생긴 연결. 후자만 제거. (1장)

1. 모듈성과 복잡성 — 같은 힘의 두 방향

1.1 정반대이지만 같은 뿌리

모듈성과 복잡성은 목표가 반대다.

• 모듈성: 변경을 용이하게 한다. 구성요소와 상호작용을 직관적으로 이해할 수 있다.
• 복잡성: 변경을 어렵게 한다. 시스템 내부가 읽어매는 미로가 된다.

그런데 둘이 반대 방향으로 작용하려면 공통 차원이 있어야 한다. 그 차원이 바로 공유 지식과 거리다.

공유 지식 높음, 거리 낮음  →  모듈성 높음  (함께 변해야 할 것이 가까이 있음)
공유 지식 높음, 거리 높음  →  전역 복잡성 높음  (함께 변해야 하는데 멀리 흩어짐)
공유 지식 낮음, 거리 낮음  →  지역 복잡성 높음  (관계 없는 것이 한 곳에 뭉쳐 있음)
공유 지식 낮음, 거리 높음  →  독립 모듈  (거의 이상적)

저자 원문 핵심: "모듈성은 함께 변경해야 하는 구성요소를 공동 배치하고, 공동 진화할 필요가 없는 구성요소를 분산해야 한다. 복잡성은 정반대다." (p245)

1.2 집 짓기 비유 — 통합 설계 원칙

집을 설계할 때 부엌과 식품 저장실은 가까이 둔다. 자주 함께 쓰이기 때문이다. 반면 침실과 기계실은 멀리 뗀다. 소음이 전달되는 결합을 최소화하기 위해서다.

소프트웨어도 같다.

• 함께 변해야 하는 것(높은 강도) → 가까이(낮은 거리): 모듈성을 높인다.
• 따로 변해야 하는 것(낮은 강도) → 멀리(높은 거리): 독립적 진화를 보장한다.
• 변하지 않는 것(낮은 변동성) → 두 차원 간 불균형을 용인할 수 있다.

집을 다 지은 후에도 리모델링(재조정)이 필요하듯, 균형도 한 번 맞추면 끝이 아니다. 시스템이 진화하면 세 차원 중 하나가 달라져 균형이 깨진다. 지속적인 재조정이 핵심이다.

저자 원문 핵심: "오늘은 완벽한 설계 결정일지라도 내일은 엔지니어링 부족으로 간주될 수 있다. 시스템이 진화함에 따라 세 가지 힘 중 하나가 변하여 균형을 깨뜨릴 수 있다." (p246)

1.3 복잡성 공식

COMPLEXITY = NOT (STRENGTH XOR DISTANCE)
  → 강도와 거리가 같은 방향일 때 복잡성이 생긴다.

GLOBAL COMPLEXITY = STRENGTH AND DISTANCE
  → 강하게 결합(공유 지식 높음)됐는데 멀리 흩어진 경우.

LOCAL COMPLEXITY = NOT STRENGTH AND NOT DISTANCE
  → 관계 없는 것들이 한 공간에 몰린 경우 (낮은 응집력).

2. 결합의 세 차원 — 최종 종합

2.1 세 차원이 한눈에

2.2 균형 공식 해석

BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY

이 공식을 일상 언어로 풀면:

"함께 변하는 것은 가까이, 따로 변하는 것은 멀리 두어라. 단 거의 변하지 않는다면 이 원칙을 엄격히 지키지 않아도 된다."

세 가지 경우:

1. 강도 높음 + 거리 낮음 (XOR=0): 함께 변해야 할 것이 가까이 → 모듈성. 균형.
2. 강도 낮음 + 거리 높음 (XOR=0): 독립 변화하는 것이 멀리 → 독립. 균형.
3. 변동성 낮음 (NOT VOLATILITY=1): 어떤 조합이든 → 균형. 실용적 허용.

저자 원문 핵심: "균형 잡힌 결합 공식은 시스템이 변경을 겪을 때 모듈성의 중요성을 부각시킨다. 높은 변동성에 직면하여 공동 진화해야 하는 구성요소를 서로 가깝게 배치하고 그렇지 않은 구성요소를 멀리하면 변경을 구현하는 데 필요한 인지 부하가 줄어든다." (p245~246)

2.3 오케스트라 비유 — 부분과 전체의 균형

오케스트라를 생각해 보자. 바이올린 파트는 함께 움직여야 하므로 가까이 앉는다(높은 강도 + 낮은 거리 = 모듈성). 반면 타악기는 다른 파트와 독립적으로 연주할 때가 많아 멀리 앉는다(낮은 강도 + 높은 거리 = 독립).

지휘자(설계자)는 전체 사운드(시스템 목적)를 위해 언제 어느 파트를 가까이·멀리 배치할지 결정한다. 그리고 곡이 바뀌면(요구사항 변화) 배치도 달라진다.

소프트웨어 설계자도 같다. 현재 요구사항뿐 아니라 변화의 방향을 읽어 파트 배치를 조정한다.

3. 글쓰기 비유 — 맺음말의 핵심 통찰

저자는 맺음말에서 텍스트를 비유로 쓴다.

"한 단어를 바꿔야 한다면 어떻게 될까? 이 변경의 영향은 무엇일까? 같은 문장의 다른 단어들도 아마 변경해야 할 것이다. 같은 문단의 다른 문장들은 어떨까? 아마 그것들도 변경해야 할 것이다. 원래 변경사항이 중요한 것이라면 같은 장의 다른 문단에 영향을 미칠 수 있다. 다른 장에 영향을 미칠 수 있을까? 그럴 수도 있지만, 가능성은 더 낮다." (p247)

이 간단한 구성 원칙이 소프트웨어 설계의 핵심이다.

• 단어 → 문장 → 문단 → 장 → 책: 관련된 것을 가까이, 덜 관련된 것을 멀리
• 메서드 → 클래스 → 서비스 → 시스템: 책임에 따라 가까이·멀리 배치

그러면 변경이 예측 가능한 범위 안에서 전파된다. 단어 하나를 바꾸면 같은 문장 안 단어들이 영향받지만, 다른 장의 단어들은 거의 영향받지 않는 것처럼.

4. 언제 무엇을 적용하나 — 의사결정 가이드

4.1 설계 시작점 — 변동성부터 파악한다

[1단계] 변동성 파악
  이 구성요소는 핵심 하위 도메인인가?
    → 예: 변동성 높음 → 균형에 엄격
    → 아니오: 지원/일반 → 불균형 허용 가능

[2단계] 강도 결정
  어떤 종류의 지식을 공유해야 하는가?
    → 침입(private 침범): 항상 제거 대상
    → 기능(비즈니스 로직 공유): 밀접 관련 기능이면 허용
    → 모델(도메인 모델 공유): 진화 속도 고려
    → 계약(인터페이스만): 가장 낮은 강도, 권장

[3단계] 거리 결정
  강도와 방향을 맞추는가?
    → 높은 강도 → 가까운 거리 (같은 모듈/서비스)
    → 낮은 강도 → 먼 거리 (별 서비스/팀)
    → 강도·거리 불일치 → 복잡성 증가

4.2 상황별 적용 예시

4.3 균형이 깨지는 신호 (11장 재조정 트리거)

• 변경 한 곳에서 예상치 못한 다른 곳 깨짐 → 강도·거리 불일치 (전역 복잡성)
• 한 모듈이 너무 많은 일을 함 → 낮은 강도인 것들이 가까이 뭉침 (지역 복잡성)
• 단순 기능 변경에 여러 팀 협의 필요 → 조직 거리 > 기술 강도
• 핵심 도메인 변경이 일반 하위 도메인까지 파급 → 변동성 전파 차단 필요

5. 실무자에게 주는 마지막 메시지

5.1 책의 핵심 통찰 — 세 문장으로

1. 결합은 설계의 적이 아니라 도구다. 결합이 없으면 시스템은 존재할 수 없다. 진짜 과제는 결합을 없애는 게 아니라 어떤 종류의 결합을, 어디에, 얼마나 두는지 결정하는 것이다.

2. 모듈성과 복잡성은 같은 힘(공유 지식 × 거리)의 방향이다. 공유 지식과 거리를 맞게 정렬하면 모듈성이, 어긋나게 두면 복잡성이 생긴다.

3. 균형은 고정 상태가 아니다. 오늘의 완벽한 설계가 내일은 기술 부채가 될 수 있다. 변동성·강도·거리 중 하나가 바뀌면 균형도 재조정해야 한다.

5.2 패러다임은 바뀌어도 원칙은 남는다

1960년대 어셈블리 시절부터 2020년대 마이크로서비스까지, 기술 패러다임은 계속 바뀌었다. 그러나 결합을 균형 있게 다루는 원칙은 달라지지 않았다. 5장의 6수준 모델(1975년)이 지금도 유효한 이유가 여기에 있다. 같은 나무의 가지다.

저자 원문: "오래된 패러다임은 사라지고 새로운 패러다임으로 대체된다. 하지만 동일한 설계 원칙은 항상 진실이다." (p249)

핵심 개념 정리 (책 전체)

실무 체크리스트 (책 전체 정리용)

• [ ] 새 구성요소를 설계할 때 변동성(핵심/지원/일반)부터 파악했는가?
• [ ] 공유 지식의 종류(침입/기능/모델/계약)를 명시적으로 결정했는가?
• [ ] 강도와 거리가 같은 방향(높은 강도=가까운 거리 또는 낮은 강도=먼 거리)으로 정렬됐는가?
• [ ] 변동성 낮은 구성요소에 불필요한 균형 비용을 쓰고 있지 않은가?
• [ ] 결합 균형 공식 BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY를 적용했는가?
• [ ] 최근 변경 중 예상 밖의 파급 효과가 있었는가? → 재조정 트리거
• [ ] 한 구성요소가 너무 많은 일을 하는가? → 지역 복잡성 신호, 분리 검토
• [ ] 단순 변경에 여러 팀 협의가 필요한가? → 조직 거리 > 기술 강도 불일치
• [ ] 새 마이크로서비스 분리가 수명주기 결합은 줄이되 지식 결합은 늘리지 않는가?
• [ ] 이 결합이 필수인가 우연인가를 자문했는가?

연습문제 (문제만 — 정답은 부록 D)

1. 종합. 균형 잡힌 결합 공식 BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY를 일상 언어로 설명하라. 각 항이 의미하는 바와, 변동성이 낮을 때 왜 불균형을 허용할 수 있는지를 포함해 3~5문장으로 답하라.

2. 분류. 다음 두 시스템 A·B를 강도·거리·변동성 세 차원에서 비교하고, 어느 쪽이 더 균형에 가까운지 이유를 들어 판단하라.

3. A: 주문·결제 서비스가 같은 모놀리스 안에 있고 비즈니스 로직을 직접 공유한다.

4. B: 주문·결제 서비스가 별 서비스이고 계약(API 명세)으로만 통신한다.

5. 적용. 레거시 시스템에서 세 개의 마이크로서비스가 하나의 공유 DB를 직접 읽고 쓴다. (a) 이 설계의 강도·거리·변동성을 평가하라. (b) 균형을 회복하기 위해 무엇을 조정해야 하는가?

6. 판단. 어떤 팀이 공통 로깅 라이브러리를 전체 서비스에 적용하면서 높은 강도 + 높은 거리 상태가 되었다. 이 경우 NOT VOLATILITY 항이 균형을 유지시켜 준다고 할 수 있는가? 왜 그런가, 또는 왜 아닌가?

7. 설계. 당신이 설계하는 시스템에서 핵심 하위 도메인 하나와 일반 하위 도메인 하나를 골라, 각각에 어떤 통합 강도 수준을 적용할지 이유와 함께 설명하라.

최신 동향 (2026-05 기준)

최신 동향 (검증 2026-05-21)

• 모듈 모놀리스(Modular Monolith)의 부상 — 마이크로서비스 분리가 지식 결합 증가로 오히려 복잡성을 높인 사례가 누적되면서, 거리는 낮게(같은 배포 단위)·강도는 계약 수준으로 유지하는 모듈 모놀리스 패턴이 실용적 대안으로 재조명되고 있다. 강도·거리·변동성 세 차원의 최적 균형을 맥락에 맞게 선택하라는 이 책의 메시지와 정합한다.
• 서버리스·이벤트 기반 아키텍처에서 암묵적 결합 증가 — Lambda·Cloud Functions 같은 서버리스 환경에서 이벤트 스키마와 실행 순서에 대한 암묵적 기능 결합이 새로운 복잡성 원인으로 떠오르고 있다. AsyncAPI 같은 이벤트 계약 표준이 이를 명시적 계약 결합으로 격하시켜 통합 강도를 낮추는 방향으로 채택되고 있다.

부록 A. 책 전체 핵심 용어 사전

부록 B. 5장 모듈 결합 vs 6장 공생성 vs 7장 통합 강도 종합 매핑

세 모델은 같은 현상(공유 지식)을 다른 렌즈로 본다. 아래 표는 세 모델을 강도 순으로 정렬한 종합 매핑이다.

세 모델의 관계

구조적 설계(5장) — 1975년 모델. 종류별 분류가 명확. "어떤 종류"
        |
        ↓ 정밀화
공생성(6장) — 변경 전파의 깊이·강도 측정. "얼마나 깊게"
        |
        ↓ 현대화·통합
통합 강도(7장) — 5·6장을 현대 소프트웨어에 맞게 압축·재편. "실무에서 어떻게 쓰나"

각 모델은 독립적으로 써도 되지만, 세 모델을 함께 쓰면 공유 지식의 종류·깊이·실무 적용을 모두 아우를 수 있다.

부록 C. 추천 참고 자료

부록 D. 연습문제 풀이

1. (균형 공식 해석)

STRENGTH XOR DISTANCE는 강도와 거리가 같은 방향일 때 1(균형), 반대 방향일 때 0(불균형)이다. 즉 "높은 강도면 가까이(낮은 거리), 낮은 강도면 멀리(높은 거리)"를 뜻한다.

OR NOT VOLATILITY는 변동성이 낮을 때 강도·거리 불균형을 허용한다는 의미다. 거의 변하지 않는 구성요소는 설계 불일치가 있어도 실제 파급이 발생할 빈도가 낮아 균형 비용보다 불균형 허용 비용이 낮다. 실용주의적 설계 원칙이다.

전체를 한 문장으로: "함께 변하는 것은 가까이, 따로 변하는 것은 멀리 두어라 — 단, 거의 변하지 않는다면 이 원칙을 엄격히 지키지 않아도 된다."

1. (A vs B 비교)

A(모놀리스 + 비즈니스 로직 공유): 강도=기능 결합(높음), 거리=낮음(같은 배포 단위), 변동성=높음(주문·결제는 핵심 도메인). 강도와 거리가 같은 방향(모두 높거나 낮음)이면 XOR=0이므로 균형 조건 충족. 그러나 비즈니스 로직 공유는 기능 결합으로 강도가 높고 분리가 어렵다.

B(별 서비스 + 계약 통신): 강도=계약 결합(낮음), 거리=높음(별 서비스). XOR=0으로 균형. 강도가 낮아 미래 독립 진화도 용이. 일반적으로 B가 더 낮은 강도의 균형이므로 변경 유연성이 높다. 단 두 시스템 모두 균형 공식상 균형이나, B가 통합 강도 측면에서 더 바람직하다.

1. (공유 DB 평가)

(a) 강도: 여러 서비스가 테이블 스키마를 직접 공유 → 공통 결합(5장) = 기능/침입 결합(7장). 강도 높음. 거리: 공유 DB는 여러 서비스에 걸쳐 분산 → 거리 높음. 변동성: 핵심 비즈니스 DB라면 변동성 높음. 결과: 높은 강도 + 높은 거리 = STRENGTH AND DISTANCE = 전역 복잡성. 최악의 조합.

(b) 조정 방안: DB per Service 패턴 적용 — 각 서비스가 자체 DB 소유, 상위 서비스는 API·이벤트로만 데이터 제공. 지식 공유 강도 하락: 침입/공통 결합 → 계약 결합. 거리는 유지하되 강도를 낮춰 균형 회복.

1. (공통 로깅 라이브러리의 NOT VOLATILITY 허용)

공통 로깅 라이브러리는 일반 하위 도메인(낮은 변동성)에 해당한다. 로깅 인터페이스가 자주 변하지 않으므로 NOT VOLATILITY = 1 → BALANCE = 1. 높은 강도(여러 서비스가 같은 라이브러리에 의존) + 높은 거리(모든 서비스에 분산)라는 불균형이 있지만, 거의 변하지 않기 때문에 변경 파급이 거의 없어 균형을 유지한다고 볼 수 있다. 단 라이브러리 API가 자주 바뀐다면 변동성이 높아져 허용 조건이 사라지므로 재평가 필요.

1. (핵심 vs 일반 하위 도메인 통합 강도)

예: 전자상거래 시스템.

핵심 하위 도메인(주문 관리): 비즈니스 규칙이 자주 변하고 경쟁 우위의 원천. 통합 강도는 계약 결합 권장 — 주문 서비스와 외부 구성요소 간에는 API 명세(계약)만 공유. 내부 도메인 모델이 외부로 새 나가면 모델 결합이 돼 변경 파급이 커진다. 가까운 거리 유지(같은 팀/서비스)로 높은 변동성에 대응.

일반 하위 도메인(이메일 발송): 거의 변하지 않고 표준 솔루션으로 대체 가능. 통합 강도는 계약 결합 또는 일정 수준의 모델 결합 허용 가능 — 변동성이 낮아 불균형을 어느 정도 허용할 수 있고, 오픈소스 라이브러리나 외부 서비스 API 계약을 그대로 사용해도 무방. 먼 거리(독립 서비스 또는 외부 SaaS)가 적합.